Business Analyst Community & Resources | Modern Analyst

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

When Should an Analyst Suggest Using Queues in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:43:00 GMT

One of the most underrated skills for a business or system analyst in integration projects is knowing when to recommend a message queue — tools like RabbitMQ, Kafka, or Azure Service Bus.

Let’s be honest: not every integration needs one. But when it does, queues can save your system from chaos.

What Queues Actually Solve

Message queues are not just “another tech buzzword.”
They handle asynchronous communication — meaning systems don’t have to wait for each other to respond.

Example:
Instead of sending an invoice from System A and waiting for System B to confirm,
System A drops the invoice into a queue.
System B picks it up when it’s ready.

Benefits:

Smooth data flow even if one system is slow or offline
Built-in retry and error handling
Better scalability — handle thousands of messages per second
Natural decoupling between systems (less spaghetti logic)

When Analysts Should Recommend Queues
You don’t need a queue for every integration. But consider it when you see these signs:

High volume of transactions — more than a few thousand per hour.
Unstable or external systems — APIs that sometimes fail or have latency issues.
Different processing speeds — one system sends faster than another can receive.
Business-critical data — where you can’t risk data loss or duplication.
Complex workflows — where multiple consumers (systems) need the same event.

When Not to Use Queues

For real-time user interactions (e.g., “show me the balance now”) — queues add delay.
For simple 1:1 synchronous API calls — direct REST is cleaner and faster.
When the team can’t support monitoring (queues need visibility and alerts).

As an analyst, you don’t have to design Kafka topics or RabbitMQ exchanges.
But you should recognize the moment when a queue turns from “technical detail” into a business enabler — ensuring reliability, scalability, and peace of mind for everyone involved.

For Business/System Analysts who work with ERP integrations.

Andrii Siryi — Tue, 28 Oct 2025 15:42:00 GMT

When designing ERP integrations (for AR/AP document flows), Business/System Analysts often face a range of “gotcha” questions — technical, architectural, and sometimes unexpected.
Here are some of the real-world questions I ask clients during the API and ERP connector discovery phase:

What’s the minimum required ERP version to support all AR/AP endpoints?
Could upgrading the ERP version change the API behavior (fields, formats)?
Are there any heavy or slow API methods under load? Recommended workarounds?
Does the ERP provider charge for API calls, or is usage unlimited?
Can we get a list of possible API error codes?
Any record count limits per request? (e.g., max 1000 records in GET)
What type of authentication is used — Basic Auth, OAuth2, or token-based?
What’s the average response time of the API?
Are there any debug/logging tools if something goes wrong with the call?
Any breaking changes in recent patches that could affect us?
Does the API support batch insert/update or only record-by-record?
In what format are dates returned? Full datetime or date-only?
How are balances returned (positive/negative for credit memos)?
Can documents be posted without updating the "last modified" date?
Can an account include multiple subsidiaries? How to filter by them in the API?
Are any API methods planned for deprecation? What will replace them?
Are some API endpoints available only with paid ERP modules or add-ons?
Are some fields or features hidden unless specific ERP configuration settings are enabled?
Does the ERP API return full relational data (e.g., linked documents, GL splits), or do we need extra queries?
How can we detect deleted records if the API doesn’t expose a deleted flag or status?

These questions aren't just technical — they help avoid costly mistakes, failed syncs, or misunderstood logic.

Field Mapping vs. Canonical Data Model — Which One Wins in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:39:00 GMT

When building integrations between systems, one of the first architectural choices you’ll face is how to align data between them.
Two main approaches dominate this conversation: direct field mapping and the canonical data model.
Let’s break them down.

Field Mapping: Simple but Fragile

Field mapping means you connect each field from System A directly to a matching field in System B.
It’s fast to implement and easy to visualize:

Example:
“CustomerName” → “ClientFullName”
“InvoiceDate” → “BillingDate”

Pros:

Quick setup for simple integrations
Easier to debug and understand
Great for 1-to-1 integrations

Cons:

Every new system adds complexity — you end up maintaining dozens of mappings
Any field name or format change breaks the flow
Hard to scale beyond a few connections

This approach is fine for small, stable environments — like syncing data between CRM and ERP once a day.

Canonical Data Model: Structured and Scalable

A canonical model introduces a shared, unified data layer — a kind of “translation dictionary” for your enterprise.
Instead of connecting systems directly, each system maps to the canonical schema.

Example:
System A → Canonical Model → System B
“CustomerName” → “Customer.FullName” → “ClientFullName”

Pros:

Greatly simplifies multi-system integrations
Reduces maintenance costs over time
Makes it easier to add or replace systems

Cons:

Requires more design work upfront
May be overkill for small projects
Needs governance and version control

This approach shines in large ecosystems — where data flows across multiple ERPs, CRMs, or custom apps.

So… Which One to Choose?

If you’re connecting two systems and don’t expect frequent schema changes — use field mapping.
But if your integration landscape is growing and you want to reduce long-term pain — invest in a canonical model early.

Think of field mapping as a shortcut, and the canonical model as a foundation.

Product Evaluation Framework for a BA

Ashish Adike — Tue, 20 Oct 2020 22:36:00 GMT

As a Business Analyst, very often we get into a situation where the Project requires multiple IT Products to be evaluated before implementation and might seek Business Analyst’s recommendation for the same. With the ever-growing range of Products in the market and the marketing promotions associated with some of the products, it’s very easy to choose the Product with most features or the most famous one. While there are various benchmarking softwares that measure the IT products from a technical performance perspective, as a Business Analyst, it is our responsibility to make sure that the right product is chosen as we are the ones who know the Business Processes closely and at the same time are equipped to understand the features of a Product that would be well suited to address the Business Requirements. While a Business Analyst may not be the final decision maker, the BA’s analysis definitely impacts the decision-making process. A structured approach to analyze the available Products would help in choosing the best suitable IT product for the Business.

Features: It is recommended to choose a Product that has Features which meet most of the Business Requirements out of the box. Although it’s difficult to find a Product which would satisfy 100% of all the required features, it’s better to choose the one with as little customizations as possible. Customizations would often mean force fitting a Product for a Business Process and may have downstream impact in future. Also, it would involve high maintenance costs to maintain a highly customized Product. As a Business Analyst, we need to provide a Business Process vs Feature mapping for each of the IT Products in question, which would enable the Stake holders to choose the IT Product satisfying the most relevant and critical Business Processes.

User Experience: As a Business Analyst we generally work closely with the Business Users and can gauge the pulse of the Users. It is important that any IT Product chosen provides a good User Experience as it would drive the user adoption and hence the success of the Project. The Business Analyst needs to capitalize the demos provided by the respective IT Products to determine the User Experience levels. Also, many IT Products are available on a free trial version, which can be utilized to get a feel of the Product hands-on before actually implementing the same.

Support: Once an IT Product gets implemented and as the Business Users start adopting it, we see a lot of enhancement requests coming from the Business Users to improve the existing implementation. Also, there might be Bugs in the Product which got missed in the testing process but arise only when the users start using the Product. In order to resolve the issues and implement the enhancement requests, it is critical to have a good post implementation support from the respective IT Product Vendor.

Ease of access: The ease with which Users can access an IT product also plays a vital role in determining the right Product. A Product which can be accessed from any web browser (i.e. Cloud) would always rank better as compared to a desktop based (i.e. on premise). It would even be better if the Product can be accessed from a Mobile device. With the work-from-anywhere concept gaining prominence, the Cloud based, and Mobile enabled Products would see an upward trend in demand.

Product Roadmap: It is important to consider the roadmap the IT Product has planned for implementing various out of box features as that would help us in planning our implementation and make decision on the level of customization that needs to be done during the initial release. The IT Product with promising features suitable to the Business Requirements needs to be given a higher priority as compared to that without a suitable Roadmap.

Although the cost and performance of the IT Product might be considered by the Management, a careful analysis of the IT products with respect to above listed parameters would help the Stake Holders in choosing the right IT Product for long term.

About the Author:

Ashish Adike is a seasoned Business Analyst with more than 8 years of experience in Business Process Analysis, Requirements gathering, Consulting, Solutioning and Project Management. Experienced in working with multiple Business functions – Sales, Marketing, Finance, Operations. Strong research professional with a PGDM focused in Sales and Marketing from Indian Institute of Management, Indore. Awarded team player with excellent learning and adaptability skills.

Requirement vs specification

Neetu — Sat, 07 Mar 2020 16:58:00 GMT

As a business analyst, we capture client requirements in different documents like BRD (business requirement document), FSD (functional specification document) and SRS (software requirement specification). If we are capturing the requirements in these documents, then why the document nomenclature is different? The answer is Yes. We are capturing the requirement but from different perspective. That’s why the document nomenclature is different.

Requirement refers the business need from the perspective from business user whereas the specification defines those requirements from system perspective. Requirements document what is needed whereas specifications document how to achieve the requirements.

The requirement represents the problem or need whereas the specification provides the solution to that problem/ need.

The requirement is gathered from business user/ stakeholders whereas the specification is provided by technical team keeping requirements in mind.

The input for requirement is the business users whereas the input for specification is requirement document, business users and technical team.

The output for requirement is requirement document like BRD, concept note whereas the output for specification is specification document is SRS, FSD.

The combination of complete, clear and concise requirement as well as specification is the recipe of fulfilling business user's need and to retain clients.

When is Security not a Non Functional Requirement?

Peter — Tue, 22 Aug 2017 18:12:00 GMT

If you are building a reusable Security Product tool to specifically address Security Technical Implementation Guide (STIG) Findings, should the requirements be considered Non Functional Requirements or Functional Requirements?

For example if there are a number of STIGs such as:

The minimum password length shall be 15 characters
The maximum password length shall be 30 characters
The password shall contain at least one of each of the following types of characters
1. Numeric Character
2. Uppercase Alphabetic Character
3. Lowercase Alphabetic Character
4. Special Character (!,@,#, etc.)
The password shall be changed a maximum of every 60 days

should I add them to the Functional or Non Functional section of my Requirements Document.

Add your answers and thoughts in comments below:

Are You Being a Design Illusionist?

Paul Crosby — Wed, 07 Sep 2016 14:31:00 GMT

As business analysts, we are often in the fray of designing. Whether it’s a user interface, report or data fed from one system to another; business analysts create interfaces with human beings and systems. Our design choices impact users and other systems in a very real way. This power can go unnoticed even in our own minds.

Have business analysts become illusionists and pickpockets? Both these skill sets require some of the same sleights of hand. The illusionist uses the blind spots and limits of human vision to fool us. If you haven’t had an opportunity to watch the show called “Brain Games” – give it a whirl. It does an excellent job of explaining how an illusionist can fool our sight and point of view. For the pickpocket, it’s the distraction of a conversation, a tap, or a bump to set your mind off in the opposite direction of where you should be focusing while a sleight of hand takes your wallet.

Are we as business analysts playing a role of illusionist and pickpocket when designing our interfaces? Let’s look at interfaces (such as screens and reports) in a broader sense. An interface in my mind is the presentation or “stage” an illusionist would use.

We all believe we have choices and freedom. Everyone in the western world most firmly believes they have great freedom of choice in being able to do whatever is desirable, affordable and of course legal. You can go just anywhere and do just about anything. But when confronted with a system, website or application with a menu of choices, we fail to see how we are hijacked.

We rarely ask the questions:

(1) What is NOT in the interface? Or why are these my only choices?

(2) What is the purpose or goal of this interface? What is it used for?

(3) Why are these options higher or lower on the interface? More visible or less visible as other choices?

(4) Are these choice empowering me or just distracting me from doing what I need to accomplish?

If you have every used a search engine like Google or an application like Yelp, you get a sense choices are made for you and only certain things are being presented for your attention. I have been told the nearest restaurant or gas station is several miles away – all the while standing right in front of one! I usually chalk it up to “well they must not have gotten into the database yet” but now I’m leaning more to thinking I’m being fooled by the choices I’m presented.

Back in the ancient days at the dawn of computerized civilization – something like 40 years ago for you youngsters – computers were called mainframes. Mammoth monsters that would manage large amounts of data, electricity and generate a lot of heat. They required a forklift to move and had to be water cooled.

In those ancient days of computer myths and data Gods, there was but the humble green screen. To get to all the crap stored in that giant mainframe required you to issue the magic commands. By locating the secret words in the sacred text called “Command Line Reference,” you could instruct the mainframe beast to perform feats of great wonder. In other words, there was a giant three-ring binder with all these commands listed in alphabetical order that you were required to memorize and type correctly. The mainframe didn’t tolerate spelling mistakes, and there was no such thing as auto correct. No Google-like “Is this what you mean?” ever appeared on the screen. Even the help key which was supposed to provide assistance rarely did. This was the world of complete freedom from “the menu”. All the commands were in the book and available and granted they didn’t cover everything you wanted to do, but they did cover a lot of stuff you needed to perform. Yes, you had to memorize a boat load of command line syntax because the mysterious book appeared and disappeared as it desired, but you never felt limited rather you just felt a need to search for the right command.

Enter the age of the personal computer. For simplicity, the command line went away. The mouse was born. There was nothing more entertaining than watching grown men in a room holding the mouse with both hands tightly but gently trying desperately to get that arrow moving in the right direction on the screen. “This mouse thing will never catch on” they grumbled. Suddenly the command line was gone, and menus or buttons presented to us. These were your options. Your only available commands. It didn’t take long before I missed my giant 3-ring binder of commands that gave me all the power.

Over time we became to believe that only the commands we could see were the ones of importance. We would become less and less frustrated at not seeing the things we needed. We are restrained by choices of actions presented. Our perception came to be that if it wasn't presented, it wasn't available.

So let’s take this into the modern smartphone age. The other night friends and I were out at a restaurant having a great conversation. The restaurant was closing because it wasn’t that busy and the owner wanted to call it a night. We asked each other the question “let’s continue this conversation – where should we go?”. We all pulled out our smartphones pulling up Google, Yelp, and the other thousand apps on our smartphones looking for a place that was open late. This searching went on for 15-minutes or so. Now I can be a bit impatient with technology and frankly don’t always find it of much help in situations like these. I quit my search letting the others wade their way through the digital data flowing around with smartphones. Then I looked up.

A beautiful park lay right before our eyes across the street, and we didn’t even see it. We believed our only options to find some place were those our smartphones provided. Did those applications tell us about the park? Not one. How about that food truck with the fabulous desserts? Nope. Not a single one. Our illusion of having choices was broken. Sure we got a lot of options, but it was all about the pictures of the menu or comments from other people that distracted us from answering the exact question “Where should we go to keep talking?”. The menu or interface design didn’t answer our actual question at all. It created the illusion of choice by presenting a small subset of options. All said and done the park was bug-free which is a miracle in Minnesota some evenings. Dessert and conversation continued for hours in the street lamp lit park.

As business analysts or designers, it is easy just to limit user choices to a few as possible to send them down a well-defined and perfectly groomed path. But does that answer their question? How many times have you wanted to say “Siri – lead the way to a great evening with my friends!”. The response from Siri is, “I’m sorry I don’t’ understand what you are asking”.

There are a thousand paths to getting or achieving something. No matter how hard you try to make it simple, it just winds up being even more complicated. Or worse the real thing you need is hidden somewhere because someone felt it wasn’t’ important enough to warrant a button. Some of the best interfaces look very simple on the front end and have a rich set of commands just slightly inside of the interface. As a business analyst and designer, we need to give our users or community a rich experience with our application. Are we the illusionist – forcing users down only one path? Our accounting system has several ways in which to generate an invoice. From a customer contact screen, main menu, sidebar and I’m sure more options remain hidden in the accounting interface. As I watched the finance, customer service, and sales people utilize the user interface with the simple task of generating an invoice, I noticed something important. Not everyone went about taking the same path.

Sales people always went to look at the customer inquiry screen first before generating an invoice. Individuals and their contact information were more important to them, and they would update it before moving on to creating an invoice. Customer service created invoices from the order screens as they were more focused on shipping products. Finance folks just clicked on the main menu option.

Know your users. They each have a story and a way of performing tasks that make sense to them. Think about their “persona” and what they need to accomplish. There is no single path to creating an invoice. Develop a list of capabilities and make sure they are not “hidden” from view. If it all doesn’t fit on a screen, find ways to expand the options for display when requested. Don’t fear including two buttons “Create Invoice” and “Add Invoice” which go to the same screen if it makes more sense to a broader audience of users. It is more about clarity for your users then consistency in terms.

What has a dinner in the park taught me? Smartphones are not as smart as we think they are. Everyone thinks they have choices, but don’t always see the most obvious choice because the choice is not presented in a way the user would understand. Question the choices presented and determine if they are the only choices.

Yes, I still miss my green screen terminal. CMD-1 key forever will mean “useless” help, and a blinking green bar on a black screen will always be a symbol of the endless possibilities to mistype ridiculously long string of text that doesn't make sense to anyone. And that huge 3-ring binder filled with commands-a-plenty works damn good propping the door open.

For more good stuff on business analysis and leadership, check out the blog at Bob the BA.

Stakeholder Requirement: Clarified

Praveen Udupa — Fri, 06 May 2016 10:54:00 GMT

This is in continuation of my earlier post on Business Requirement. If you have not read that post, I recommend you take a few minutes to study that first before continuing with this post.

In this post, let's discuss Stakeholder Requirement. Some people refer to this as User Requirement, but BABOK's nomenclature is Stakeholder Requirement. Understandably so, because a User (i.e. End User of the solution) is just one type of a Stakeholder. Other Stakeholders, not necessarily Users of the solution, may also have needs that they need satisfied by the solution.

Stakeholder Requirement describes how a given stakeholder would like to interact with the solution, in the context of a business requirement.

Let's observe a few points from the above definition of a Stakeholder Requirement:

1. We already know that Business Requirements must not include the solution. We have discussed this in my previous post. But while defining Stakeholder Requirements, the solution approach must be selected. How else would the stakeholders describe how they would like to interact with the solution?

2. If the solution approach changes, the Stakeholder Requirements also change (but the Business Requirements do not change)

3. In the hierarchy of Requirements, Business Requirements are at the top, immediately followed by Stakeholder Requirements. Every Business Requirement gets decomposed into its constituent Stakeholder Requirements. Stated the other way, one or more Stakeholder Requirements trace into one Business Requirement.

4. Stakeholder Requirements are not at a level of detail for the implementation team to design and develop the solution.

Let’s take an example to understand this better. In my previous post, we had discussed the example of an Insurance Company whose Business Requirement was Ability To Collect Premium Remotely. In order to meet this Business Requirement, there are several solutions possible:

First obvious solution: enable internet and mobile payment
Enable direct debit from the customer’s bank account
Partner with one or more banks and enable the banks to collect the premium
Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
Establish several satellite premium collection centers

Suppose we select the internet solution, i.e. the insurance company builds a website where customers make premium payments. The following would be some of the Stakeholder Requirements:

Customer: Ability for a Customer to view a list of all policies where premium is due

Customer: Ability for a Customer to make a payment for policy where premium is due

Admin: Ability for the Admin to update the list of policies where premium is due for all customers

Stakeholder Requirements form the basis for defining Solution Requirements. One might ask why bother defining Stakeholder Requirements at all, if it is not useful for the implementation team to design the solution. The reason is simple: A top down structured approach will ensure that the requirements coverage is close to 100%, and the probability of missing out on requirements is very low. Besides this, this approach helps minimize scope creep. I will write more about this in subsequent blogs.

Business Requirement: Clarified

Praveen Udupa — Fri, 06 May 2016 09:38:00 GMT

"Business Requirement" is a maligned phrase. Different people have different interpretations for what it means. The worst interpretation that I have come across is, “hey, if the requirement comes from a business stakeholder, then it is a business requirement”. Requirement from business is NOT business requirement. For God's sake, every requirement comes from a stakeholder, otherwise it is not a requirement.

In this blog, I wish to clarify what exactly is a business requirement. I base this entirely on the best practice definitions documented in the BABOK v2 (and v3…truth rarely changes!)

Let’s take a short case:

Assume there is an insurance company that is dealing with a sticky business problem: they have a significant proportion of the policies lapsing by the first anniversary. In other words, the customers who buy an insurance policy today do not renew it the following year and, instead, let the policy lapse. Upon performing root cause analysis, the insurance company determines that the customers do not care to renew their policy because they don’t like to travel all the way to the branch office to pay the premium in order to renew their policy. In fact, they find commuting to the branch office so troublesome that they find it acceptable to let their policy lapse.

Now, what does this insurance company need to deal with the policy lapsing problem?

The insurance company requires an Ability To Collect Premium Remotely. This is a business requirement.

According to the BABOK, a business requirement is simply a statement of goal, objective or outcome of why a change is initiated. (Please see my P.S. at the end of this article)

Let’s take a closer look at the above business requirement:

Business Requirement exists in the Problem Domain. It captures the need of the business in order to eliminate a problem (actually the symptom). If the insurance company develops the ability to collect premium remotely, then, according to the root cause analysis, more customers will be willing to renew their policies, and consequently the lapse rate will decline.
Business Requirement MUST NOT capture how it will be met, i.e. the statement of business requirement must not include the solution. This is important. Very important. Well, why is this so? There are a couple of reasons:
1. First: Business requirements are developed during Enterprise Analysis (BABOK v2) or Strategy Analysis (v3). To be more specific, they are developed after assessing current state of the organization. At this point in time, no one even know what the solution is because it is not yet identified. Hence the question of including the solution in the statement of business requirement does not even arise.
2. Second: there always are multiple potential solutions that can be employed to meet a business requirement. If the statement of business requirement includes a solution, one would tie the organization to the said solution without considering any of the other solutions. In the above insurance company example, there are several solutions possible:
  - First obvious solution: enable internet and mobile payment
  - Enable direct debit from the customer’s bank account
  - Partner with one or more banks and enable the banks to collect the premium
  - Authorize the agent to collect premium on behalf of the insurance company. The agent may then provide door collection service
  - Establish several satellite premium collection centres

As you can see, any one or more of the above solutions will provide the remote premium collection ability to the insurance company. Thus, it is not prudent to include the solution in the statement of business requirement.

Most people whose role/designation is Business Analyst operate in the IT space. They define the requirements for an IT solution. More often than not, these BAs do not get to define the business requirements because they mostly never participate in Strategy Analysis projects. However, every BA participating in defining the User and Solution requirements MUST begin by understanding the Business Requirements.

More on this in my subsequent blogs...but for now, I will look forward to your comments!

P.S:

BABOK is probably confusing for a first time reader (even if this first time reader is a seasoned BA). The BABOK makes a confusing statement - it says business requirements are high level statements of goals. This seems incorrect because a goal and requirement are clearly two different things. Here is how I reconcile various terms:

First comes Business Strategy
Business Goals are defined from Business Strategy
Business Objectives are SMARTly decomposed from Business Goals
Business Requirements are high level statements of goals (not Business Goals) in order to eliminate a Problem that is preventing the org from meeting its Objectives, without including any indication of the Solution in its statement
Stakeholder Requirements (or User Requirements) are needs of Stakeholders from the selected Solution, in the context of a Business Requirement
Solution Requirements define the behavior of and constraints imposed on the Solution in order to deliver the Stakeholder Requirements

Top 10 mistakes in Use Case Modelling

Trividh Patel, CBAP — Mon, 11 Jan 2016 03:10:00 GMT

Use case modelling is the most powerful requirements modelling technique to model solution requirements if applied correctly. I have come across many BA teams (including my own) that made lot of common mistakes in use case modelling. By avoiding the top 10 mistakes identified in this paper, BA teams can not only save lot of efforts in use case modelling but also significantly enhance the value delivered and improve the satisfaction of stakeholders.

1. Naming the actors using the job titles

Job titles and actor names are two different things and often cause confusion. This is because two different users, with different job titles and organizational responsibilities, may have to use the system as a same actor; for example, a supervisor can have access to and use the functionality used by his/her subordinate. Actor is a role that is with respect to the system as opposed to a job title which a role with respect to the organization. Job titles may typically determine user types. Remember, job titles of people may change but the roles they play would remain relatively stable.

2. Creating only the use case diagrams

Use case diagrams only provides summary of the relationship between the actors and the use cases. Can we tell what a system does basis only the use case diagram? No; a system cannot be built just based on the use case diagrams. We need detailed use case descriptions to design and build the system.

3. Not capturing enough details

Too much detail can obscure the flow of the use case and too less can make it really meaningless. “How detailed a use case should be?” In as much detail as possible and in as much detail that is required to make them unambiguous to describe what the system must do. Focus on what is important and continue to add details till all the stakeholders are satisfied.

4. Describing everything a system does in a use case

It is important to identify all the use cases and describe them so that everyone understands who uses the system and what goals they achieve by using it. This is particularly important when the user-system interaction is complex and detailing the system behaviour is essential to develop and test the system. However, if we blindly do this for all the use cases than we are just increasing the documentation and subsequent time required for reviews and sign-off, without delivering any additional value to the project and its stakeholders. So, for cases where the user-system interaction is simple, use cases are not required to be fully described. In such cases, a simple use case description supplemented with declarative requirements and other models may be sufficient to understand what needs to be done.

5. Performing functional decomposition

BA teams typically tend to group functional requirements, or break them in form of functions or menu-items and identify them as use cases. What they don’t understand is, high-level use cases cannot be decomposed into lower-level use cases and also use cases cannot call, communicate, get linked or sequenced with other use cases. This approach is most common of all mistakes made while identifying and describing use cases. Let us try to understand this with an example.

What use cases will you identify for a system say, a car? The adjoining diagram shows the use cases identified using this approach. Here, all the necessary functions (menu-items!) are available to a ‘Car Driver’ (actor) to drive a ‘Car’. With this approach, are we answering what the ‘Car Driver’ will do to drive (actual goal) the ‘Car’? None of the use case actually describes the way ‘Car Driver’ will interact with (or use) the ‘Car’ to drive it without linking or sequencing them. The system appears as a large set of disconnected functions. To identify the right use cases, always keep in mind the goal that the actor wants to achieve by using the system. Each use case must be complete to provide value to at least one of its actors.

6. Writing perfect use cases

There is no such thing as perfect use cases. Many BA teams waste their efforts in trying to create perfect use cases. The focus should be on making use cases as good as required for facilitating communication amongst stakeholders to achieve shared understanding of requirements and moving to system design, development and testing.

7. Detailing use cases with the CRUD behaviour

Although it is not technically wrong but detailing uses cases with CRUD (create, retrieve, update, delete) behaviour, for example maintaining information for administrative systems, is a waste as it is mere repetition of declarative form of requirements specifications. Use cases with the CRUD behaviour don’t add much value to ensure that the system is doing right, particularly when information can be added in any sequence without any dependency. Except for data validation rules and specific fields to be entered, the use cases with the CRUD behaviour become repetitive. These efforts can be used for detailing use cases with real flow of events.

8. Using the use case model to design the system

Many times, BA teams also document how a system should handle certain functionality internally as part of use case descriptions. By specifying such functionality we are imposing constraints on the development team to design the system in a specific way. Many would argue that “it is a BA’s job to think for all scenarios and provide a solution” but we forget that the real purpose of a use case is to describe what system does to fulfil the goals of the actor and by mentioning constraints inside a use case we are just making this behaviour difficult to understand. So, anything that must be handled in a certain way should only be described in the use cases and all other things should be left out for the developers to decide. Constraints can be captured in other specifications and traced back to the use cases so that they are not forgotten during the system design. Use case model must never be used to design the system. Use cases describe what the stakeholders want the system to do and not how the system implements the functionality.

9. Describing things outside scope of system

Use case model captures the interactions of actors and the system and describes what the system does to fulfil actor goals. Outside system boundary a stakeholder (identified as an actor) may interact with another stakeholder (who may be identified as another actor); to support the business process. If this interaction (business process) is not supported by the system, it should not be captured in the use case model. Use cases can be used to capture business processes as “business use cases” with actors outside the business boundary. Never mix systems use cases and business use cases.

10. Misusing the use case relationships

BA teams also spend lot of time structuring the use case model, with use case relationships such as include, extend and generalization, assuming that such structure is required in every use case model or required for the system’s architecture. BA teams typically useinclude relationship to break a use case into smaller use cases by performing functional decomposition of the system. The result is that none of the use cases by themselves provide any real value as it becomes very hard to see what a system does. Using use case relationships without understanding their real purpose just results into a confusing use case model.

About Author

Trividh Patel, CBAP® has well over a decade of experience in an IT services industry, in various functions such as Business Analysis, Business Technology Services, Presales, and Project Management, primarily in Banking, Financial Services, and Insurance domain.

Trividh has done his MBA from JBIMS, University of Mumbai, and Bachelor of Engineering from VJTI, University of Mumbai.

Trividh Patel, CBAP® provides specialized Business Analysis Trainings, such as

1. Fundamentals of Business Analysis
2. Mastering Use Case Modelling
3. CBAP® / CCBA® Certification Prep Course

Trividh Patel can be reached on -
LinkedIn: http://www.linkedin.com/in/trividhpatel

5 Pitfalls to Avoid in the Requirements Development Phase

Ken Young — Wed, 07 Aug 2013 17:37:00 GMT

Developing requirements is a process with many moving parts. It involves aligning multiple stakeholders from different areas within an organization to determine what must be developed to fulfill a business need. Because it is a process, there are a number of factors that can cause the process to break down and lead to the development of faulty requirements:

Lack of Clear Objectives: Every application is built to play a role in some larger business context. When the business client is unclear in communicating the purpose of the application, or stakeholders lose sight of the application’s business context, the requirements in all likelihood will “miss the mark”, lacking essential functions and including unnecessary features.
Lack of Stakeholder Involvement: One of the biggest challenges in the requirements process is getting stakeholders to invest their time, over multiple elicitation sessions and then multiple review cycles, to carefully examine the requirements and provide feedback. When stakeholders are inaccessible, or are not invested in the project during the early phases, requirements flaws can remain undetected until after development begins.
Inconsistent Information Gathering: When developing complex applications, a team of business analysts will often be involved in gathering information. When inconsistent elicitation approaches are used to gather and record information, it becomes difficult to categorize, prioritize, and ultimately reconcile the often conflicting needs of different stakeholders.
Information Overload:The traditional reliance on recording requirements in long, unwieldy text-based documents not only leads to misunderstanding, but also contributes to stakeholders’ lack of involvement in the requirements development process. Using long text-based documents makes it hard for end-users and business clients to picture how the application will behave, and what may be missing.
Poor Expression: To review requirements, and ultimately build applications, all stakeholders, from the business client and end-user to the application developer and tester must be provided information in formats and using language that each can understand. Delivering information in forms that don’t take into account the different types of stakeholders inevitably leads to flawed requirements and the development of applications that don’t fulfill the objectives of the business.

When developing requirements, check to ensure that you have avoided the pitfalls above and your requirements are much more likely to be complete and effective.

Ken Young works for Blueprint, The Requirements Company. He can be reached at ken.young@blueprintsys.com.

How to convince stakeholders of BA value for the first time?

Lee Grinberg, CBAP, PMP — Fri, 21 Jun 2013 13:46:00 GMT

In my previous posts I outlined how I was able to succeed being the first and only BA at a company and the importance of establishing trust between you and the stakeholders.

So you're the first BA at a company. All are looking at you and thinking what can this person do for me?

Good question. What can you do for them?

Show them how your contribution will make their life easier!

I'll tell you how I handled this challenge. I was brought in to write functional specs based on business requirements. The business requirements were good but not complete. The IT folks were afraid that key use cases were missing.

I took the following steps:

Created a context diagram (first one in the company) to show them what scenarios may be missing
Created use cases from the business requirements
Reviewed both with the SMEs. This uncovered many gaps not covered by business requirements

Once gaps were uncovered, the people writing the business requirments were relieved to know the gaps were identified early in the process and not in a later (embarassing) stage. I made their life easier and this was appreciated.

The next steps were around design:

Wrote a detailed functional spec outlining database and functional changes
Clearly wrote out testing scenarios

So what, you may be thinking. After all, this is what BAs do. True, but remember, I was the first and only one in the company so no one was convinced of the value of a BA.

The result of design was that developers were relieved to know they didn't have to have lengthy conversations with the end users about functionality.

The key concept again is to make their life easier!

Once trust is established, however, you must prove that you can benefit the stakeholders.

Eliminating Software Documentation

Leslie — Mon, 22 Mar 2010 10:25:00 GMT

Not a suggestion for eliminating the process of documenting a software application, but rather a proposed for replacement of the documenting activity and manually produced documents with something more manageable and less likely to frighten the development team.

Initiative for this work comes from a number of discussions I have been following and also an expansion of ideas I have recently documented about best practices for software development.

1.1 Introduction

Developers nightmare – you have spent endless sleepless nights thinking about finally getting your software ready for deployment. It compiles and runs without error. It has been tested and passed user acceptance testing. It is finally ready to be released .. but, you are told that it may not be deployed until the documentation has been approved.

You have been neglecting those 200 page templates that have lying in your inbox while getting your software to compile. Now you have to spend another umpteen nights in the office writing about what it is that you have produced – yawn!

This is not a task that is going to enthuse you to do a quality job. You will probably do your best to get the documents approved asap .. anything to get your code deployed so that you can spend some quality time with family and friends.

Is this a situation you have found yourself in? I have. When I was younger, I quickly learned that this is the downside to the job of being a software developer.

Supposing though, that all you needed to do to get your software deployed, after it was already ‘working’, is to check that everything is up-to-date and consistent, post your deliverables to a ‘release’ area and organize a review meeting, with follow-up!

The following is not meant to be a complete solution, but some ideas for eliminating that boring ‘produce documentation’ task, that always seems to follow any software development effort, not only for programmers, but any member of a development team effort, including analysts, architects, testers, UI designers and any other role that produces work that needs approval.

1.2 What

Instead of identifying a document for delivery as part of a software effort, I propose to break the document into 2 components:

· the document template, and

· document contents.

Where a document has previously been identified as a deliverable, identify the document template as a deliverable. In many cases this allows for several previously deliverable documents to be replaced with a single deliverable – the template that is subsequently populated with the document contents.

This leads to 3 major activities:

· creation and management of document templates,

· production of the contents populating the template(s),

· compilation of the document from its template and contents.

1.3 How

1. Identify the stakeholders that require information that is not part of the compilable software.

2. For each stakeholder, list the information that they require in order to approve the product.

3. Work with each stakeholder to create (or select from a library) the format for a template that is an acceptable method of presenting the required information.

4. Identify dates for the delivery(s) of each template and its needed contents, and track the progress of each.

1.4 Process

For each task under How consider something along the lines of the following activities.

1.4.1 Identify Stakeholders

Stakeholders are anyone within or outside of the development team with an interest in the progress of the product. Anyone not requiring information from the product development effort, is probably not a stakeholder. Typical examples are:

· End users – who would like to see early examples of the user interface and a description of how it operates.

· Project managers – who want to be able to track the progress and effort of everything in the product repository.

· Testers – who will need to be able to access the product requirements in order to maintain test cases.

· Business owners – who will want to k now the scope of the product releases and which requirements are going to be satisfied at each release.

1.4.2 List Information

In the past when each stakeholder has been asked for their needs, they would typically turn to an existing document for reference. This document is often stripped of its current contents and has its contents replaced with information for the new product, without consideration for whether the information is ‘really’ required.

Instead, try starting with traditional document templates and work with the stakeholder to:

1. identify which sections they ‘really’ need,

2. describe the reason for this need,

3. write a description of what is documented in order to satisfy this need,

4. identify a product development timeframe for this information to be available.

Each item of information is given a location in the product repository, and duplicate information is consolidated.

Create a public interface location that always contains the latest version of each piece of information. This is the ‘release’ area.

1.4.3 Accessing Information and Publishing Documents

In many cases a stakeholder may not even require that information is presented in a traditional document form. If the stakeholder is comfortable with the repository used to contain the information, all they may need is easy access to that information.

Using a document sharing tool, such as SharePoint or a Wiki, it is relatively easy to create customized user pages that accesses only the information the stakeholder needs in a layout that makes it easy to access that information.

Alternatively, a scripted documentation tool, such as SoDA, may be used to parse a template and automatically populate it with information from the repository. Give the ability to produce the document to the stakeholder, and the development team need not be concerned with producing documents. They simply inform the stakeholders that a new version is ready for review, publish the information to the release location that the script accesses, and the stakeholder can run the script to extract the required information whenever it is convenient for them.

1.4.4 Delivery Dates And Tracking Progress

Attributes may be added to each repository element for delivery dates, assigned responsibility, progress, stakeholder(s) and a description of its contents. A reusable placeholder is created for each delivery type containing default information for each attribute.

1.5 Conclusion

As stated, the idea is not necessarily to remove documentation from the project, but to reduce the usage of the word on a development effort, and put emphasis on the ‘required’ contents and less on the document itself.

Advantages of this type of approach might be:

· The removal of unwanted/unused documentation.

· Tracking by more manageable chunks.

· Elimination of duplicate information.

· Removal of confusion over what is ‘most current’, since there is a single delivery area for every unique deliverable.

· An end to the developers nightmare of having to produce reams of documentation, after the ‘fun’ part is over.

I recognize that not all deliverable documents can necessarily be replaced in this manner. But maybe it is a start towards removing the dreaded word ‘documentation’ from a project’s deliverables list and maybe a compromise between agile proponents of minimizing documentation and those requiring documentation according to some sort of standard.

1.6 References

Links to articles that inspired this work.

http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=14867479&gid=1976291&trk=EML_anet_qa_ttle-0Qt79xs2RVr6JBpnsJt7dBpSBA

Best Practices

Create a product information repository that contains everything that is going to be shared amongst product stakeholders. Using this repository:

Abandon the use of Non Functional Requirements

Craig Brown — Thu, 24 Sep 2009 11:57:00 GMT

This model is provided by Don Firesmith of SEI. Note the lack of an NFR category.

Invest in User Stories

Craig Brown — Fri, 09 Jan 2009 12:01:00 GMT

User stories have a place in modern requirements management. They may not be going to replace use cases but you shoulod know how to write them well.

Invest In Good User Stories

View SlideShare presentation or Upload your own. (tags: agile scrum)